In information theory, entropy is a property of randomness. A device may have the capability to harvest random events, such as the timing of keystrokes or the movement of a gyroscope, to use as inputs to a Random Number Generator (RNG). Many applications face the important and non-trivial problem of obtaining enough entropy or randomness to generate random values, such as encryption keys. One such application is the generation of content encryption keys, session encryption keys, or other keys for over-the-top (OTT) delivery of Video On Demand (VOD) as well as live content. The problem is more acute if content encryption keys change periodically, e.g., key rotation, or if the provider uses private copies where individual viewers may be getting their own private version of content. Another application is the generation and frequent rotation of channel encryption keys in the context of Conditional Access (CA) systems, managed networks, cloud-based TV deployments, linear TV and IPTV. Yet another application is the generation of random nonces and keys for the purpose of file and message encryption or for the generation of encryption keys. One can further envision applications anywhere where random data is required, such as multi-player on-line and distributed games.
Traditional approaches to gathering entropy in computing systems involve monitoring, collecting, and aggregating various random events, such as mouse movements, timing between interrupts and disk I/O, etc. Server systems, such as in data centers and cloud server farms, that lack user interaction via a console, a Graphic User Interface (GUI), or a remote login lack some of these sources of random data. A typical server system does not have enough high-quality entropy to generate the required amount of random data even for applications that are not particularly demanding. For that reason, UNIX systems (Linux) usually provide applications with two interfaces for obtaining random data: 1) a pseudo-random non-blocking device /dev/urandom, and 2) a higher quality but blocking device /dev/random. The former device outputs data that is not truly random and is thus inappropriate for serious applications, such as encryption of premium video content. The latter device provides cryptographically strong random data but is blocking and, by itself, cannot be used to support a large scale deployment.
The scheme described above can be improved upon in known ways. One approach is to use the small amount of random data available in /dev/random and feed it through a cryptographically strong random number generator, such as CTR-DRBG, to produce a larger amount of high quality random data. Use of this approach requires the periodic reseeding of CTR-DRBG from /dev/random. This approach helps and could work for smaller deployments with pre-caching, i.e., the generation of random data before it is actually needed; however, it is not appropriate for larger scale deployments. Another approach is to outfit servers with hardware random number generators, such as one of the devices below, which are only a sampling of the available devices:                The Entropy Key by Simtec Electronics;        The TrueRNG by ubld.it; and        BitBabbler Black or BitBabbler White by BitBabbler.A random number generator based on radioactive decay has even been proposed in a paper titled “RANDy—A True-Random Generator Based On Radioactive Decay” by Markus Rohe, although it is unclear whether the latter is commercially available.        
While many of the available RNG may be of interest to researchers or more appropriate for small deployments, they may not work for large server farms due to cost or other issues. For example, each of the available hardware random number generators listed above comes in the form of a USB key and may not be easily used in a server appliance without custom modifications.
If using a 3rd party hardware RNG is not possible for some reason and there are concerns that /dev/random supplies entropy that is of low quality (plus /dev/random is a blocking device), one may choose to implement an entropy pool manager, such as Fortuna. Fortuna is a pseudo-random number generation algorithm, originally written by N. Ferguson and B. Schneier and published in Practical Cryptography, Wiley Publishing, Inc., 2003. The algorithm was specifically designed to be cryptographically secure from known attacks. An implementation of Fortuna is discussed in “Fortuna: Cryptographically Secure Pseudo-Random Number Generation In Software And Hardware” by McEvoy et al., ISSC 2006, Dublin Institute of Technology, June 28-30. In fact, one may decide to use entropy from /dev/random as just one pool and find and add other sources of entropy and have Fortuna manage these. Of course, if a given server system fails to generate high-quality entropy for /dev/random, it may be non-trivial to find alternative and better sources of entropy there.
Although generating enough high quality entropy on a server system may be difficult, generating enough high quality entropy may be even more problematic on the client side. This may be especially true if the client device is a handheld device, such as a smart phone, smart watch, set top box, smart television or some other such client device, even though a server requires substantially more entropy than any client device. Unlike a server system, providing a high-quality hardware random number generator can be even more problematic in client devices due to lower cost and smaller form factor of these devices. For example, while Android is Linux-based, Android is known to lack a quality random number generator. Also, in many cases, audits of secure solutions require designers to know exactly what sources of entropy are, while closed or proprietary client devices, such as iOS or Windows, may not disclose that information. One could once again consider utilizing an entropy pool manager, such as Fortuna, on a client device, and creating entropy pools from various physical devices, such as audio microphone, accelerometers, etc., which are available on the client device. A complication to this approach is that many client devices require applications requesting access to these physical devices to get an explicit authorization from the end user, and end users may block applications from accessing these devices, in which case the application will not be able to obtain any entropy.